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INTRODUCTION 

The  Battle  Command  Support  and  Sustainment  System  (BCS3)  is  a  sustainment  component 
of  the  U.S.  Army  Battle  Command  System  (ABCS)  suite.  The  BCS3  is  used  for  logistics  tracking 
including  in-transit  visibility  of  deployment,  redeployment,  and  sustainment  shipments;  supply-point 
asset  visibility  (AV);  equipment  maintenance  status;  and  unit  logistics  status.  In  April  of  2015,  the 
Weapons  and  Software  Engineering  Center  (WSEC)  tactical  applications  (TacApps)  team  received  a 
task  order  from  Product  Manager  Tactical  Mission  Command  to  analyze  the  BCS3  in  support  of  a 
potential  future  TacApps  integration  effort.  The  initial  analysis  plan  delivered  by  WSEC  outlined  a 
strategy  that  emphasized  analysis  of  the  National  Enterprise  Data  Portal  (NEDP)  component  of  the 
BCS3  and  its  associated  data  feeds.  This  area  was  identified  as  the  most  relevant  to  future 
integration  efforts.  The  initial  analysis  of  the  BCS3  and  its  NEDP  is  described  in  this  report. 

The  BCS3  analysis  includes  an  examination  of  the  legacy  BCS3  code  to  identify  the 
relevance  of  each  code  folder  to  a  potential  future  TacApps  integration.  The  analysis  also  includes 
identifying  and  documenting  how  each  data  feed  is  consumed  and  processed  as  well  as  identifying 
problems  that  might  arise  with  a  TacApps  implementation  of  feed  consumption.  Additionally,  as  part 
of  the  analysis,  WSEC  will  investigate  the  Global  Combat  Support  System  -  Army  (GCSS-A)  in  order 
to  identify  overlap  between  GCSS-A  and  NEDP  feeds  with  a  focus  on  areas  in  which  GCSS-A  data 
may  be  used  in  lieu  of  legacy  NEDP  feeds. 


BATTLE  COMMAND  SUPPORT  AND  SUSTAINMENT  SYSTEM/GLOBAL  COMBAT  SUPPORT 

SYSTEM  -  ARMY  OVERVIEW 

The  BCS3  is  the  only  sustainment  component  of  the  ABCS  suite.  The  BCS3  is  used  for  a 
large  number  of  applications  including  in-transit  visibility  of  deployment,  redeployment,  and 
sustainment  shipments;  supply-point  AV;  equipment  maintenance  status;  and  unit  logistics  status 
using  bottom-up  reporting. 

The  BCS3  is  designed  to  be  used  at  every  echelon,  from  company  to  theater  sustainment 
command  and  across  all  types  of  formations,  from  brigade  combat  teams  to  all  types  of  support 
brigades  and  division  and  corps  headquarters.  The  BCS3  is  the  only  ABCS  component  that  can 
operate  on  both  classified  and  unclassified  networks.  It  provides  this  broad  spectrum  of  capabilities 
across  all  formations  in  the  active  U.S.  Army,  U.S.  Army  National  Guard,  and  U.S.  Army  Reserve  (as 
well  as  formations  in  the  U.S.  Marine  Corps  and  other  governmental  organizations). 

The  GCSS-A  program  is  an  acquisition  category  1AM  Major  Automated  Information  System 
program.  The  GCSS-A  is  the  primary  tactical  enabler  of  the  U.S.  Army’s  sustainment  transformation. 
The  program  consists  of  two  components:  a  functional  component  for  deployable  forces  called 
GCSS-A  and  a  technical  enabler  component  called  the  U.S.  Army  Enterprise  Systems  Integration 
Program. 


EFFORT  SUMMARY 

To  date,  WSEC’s  efforts  have  primarily  revolved  around  configuring  a  BCS3  demo 
environment  to  work  on  the  WSEC  development  network  as  means  through  which  to  examine  BCS3 
code  and  functionality.  The  demo  environment  consists  of  six  virtual  machines  that  must  run 
simultaneously  on  a  single  host  computer.  The  demo  allows  WSEC  developers  to  view  BCS3 
functionality  with  static  data.  This  capability  enhances  WSEC’s  ability  to  analyze  the  BCS3 
codebase  and  interpretation  of  data  feeds.  With  limited  available  documentation,  use  of  the  demo 
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along  with  manual  code  analysis  has  been  one  of  the  few  practical  means  by  which  to  execute  the 
analysis  plan  to  date. 

Recently,  representatives  from  Tactical  Edge,  Inc.,  San  Diego,  CA,  visited  WSEC  engineers 
at  the  U.S.  Army  Armament  Research,  Development  and  Engineering  Center,  Picatinny  Arsenal,  NJ, 
for  a  technical  exchange  meeting  (TEM).  Tactical  Edge  operated  as  a  subcontractor  to  the 
International  Business  Machines  Corporation  (IBM,  Inc.)  during  development  of  the  BCS3  software. 
Tactical  Edge  engineers  possess  in-depth  technical  knowledge  related  to  both  BCS3  and  the  NEDP. 
Access  to  these  engineers  has  become  an  option  only  recently;  however,  the  addition  of  this 
expertise  has  greatly  impacted  the  analysis  efforts.  During  the  TEM,  Tactical  Edge  engineers 
provided  a  detailed  overview  of  the  NEDP  architecture  and  discussed  various  NEDP  data  feeds 
extensively.  This  technical  exchange  and  future  iterations  will  greatly  enhance  the  final  results  of  the 
analysis. 


POTENTIAL  ROADBLOCKS 

During  the  TEM  with  WSEC  developers,  Tactical  Edge  engineers  revealed  the  fact  that  BCS3 
is  completely  undocumented.  According  to  Tactical  Edge  engineers,  all  of  the  available 
documentation  refers  to  BCS3-NM  (node  management)  only.  While  BCS3  and  BCS3-NM  both  sit  on 
top  of  the  NEDP,  the  two  systems  are  separate  baselines  and  use  mostly  different  data  feeds.  A 
review  of  the  documentation  that  WSEC  received  from  IBM  confirmed  that  all  of  the  detailed 
documents  (i.e.,  software  design  description)  are  written  for  BCS3-NM,  not  BCS3.  The  WSEC 
developers  are  also  currently  reviewing  additional  documentation  received  from  the  Software 
Engineering  Center. 

As  part  of  the  analysis  effort,  WSEC  will  leverage  Tactical  Edge  engineers  in  an  attempt  to 
document  all  of  the  BCS3-specific  data  feeds.  This  information  will  be  included  within  the  final 
analysis.  Although  likely  lacking  in  detail  compared  to  a  contract  deliverable  software  design 
description  or  similar  document,  the  data  feed  documentation  generated  by  WSEC  will  provide  a 
substitute  for  the  nonexistent  BCS3  documentation  to  aid  in  future  software  efforts. 


NATIONAL  ENTERPRISE  DATA  PORTAL  ANALYSIS 

The  NEDP  is  comprised  of  an  Oracle  Database  lOg  referred  to  as  the  National  Data  Server 
and  several  other  components.  The  Oracle  Database  lOg  was  the  first  database  designed  for  grid 
computing,  which  is  considered  a  flexible  and  cost-effective  way  to  manage  enterprise  information. 
The  g  in  1 0g  stands  for  grid  to  indicate  that  the  database  is  grid-computing-ready.  Grid 
computing  introduced  shared  resources  through  which  an  instance  can  use  (for  example)  central 
processing  unit  resources  from  another  node  (computer)  in  the  grid.  This  improves  the  scalability 
and  performance  of  the  database.  Oracle  Database  1 0g  also  boasts  many  other  features  that 
improve  the  efficiency  of  the  system  such  as  self-tuning  features,  the  ability  to  transport 
tablesspaces  across  machines  and  operating  systems  (e.g.,  Windows  to  Unix),  automatic  database 
diagnostic  monitoring,  asynchronous  commits,  and  others. 

The  other  components  of  the  NEDP  include  a  main  forwarding  gateway/web  server  and  one 
or  more  data  forwarding  gateways  (DFG).  Together,  with  the  Oracle  Database  1 0g,  these 
components  provide  a  heterogeneous  data  source  that  aligns  various  data  feeds  into  a  common 
operating  picture,  which,  in  turn,  allows  the  warfighter  to  locate,  manage,  and  track  commodities  as 
they  move  through  the  various  aspects  of  the  distribution  pipeline.  This  also  allows  commanders  to 
view  user  defined  reports,  previously  known  as  combat  power  reports. 
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According  to  documentation  from  2012,  the  BCS3  as  a  whole  generates  10.25  MB  worth  of 
traffic  a  day  (or  about  7.12  KB/min).  This  includes  both  feeds  and  users.  These  statistics  are  taken 
from  the  production  system  in  March/April  2012.  By  comparison,  the  Command  Post  of  the  Future 
(CPOF)  is  roughly  considered  to  use  around  30  KB/sec  on  average  (this  is  an  estimated  number  and 
should  not  be  considered  authoritative).  By  this  estimation,  the  CPOF  actually  handles 
approximately  250  times  more  data  than  the  BCS3  on  any  given  day.  These  numbers  are  pending 
confirmation  by  Tactical  Edge  engineers  and  are  also  likely  to  update  significantly  as  the  feeds 
themselves  are  updated  to  increase  in  frequency.  In  terms  of  size,  the  BCS3-NM  maps  database  is 
roughly  1 60  GB,  and  the  other  databases  are  generally  in  the  range  of  several  hundred  GB. 


FEED  DEPENDENCIES 

It  is  important  to  note  that  there  are  no  dependencies  between  the  various  NEDP  data  feeds. 
If  one  feed  goes  down,  the  other  feeds  will  not  be  impacted.  Data  from  other  feeds  will  continue  to  be 
usable  and  searchable  by  the  NEDP.  While  a  feed  is  down,  the  NEDP  will  naturally  be  unable  to 
acquire  the  latest  data,  and  therefore,  certain  records  will  not  update.  The  net  result  to  the  user  is 
that  while  feeds  are  down,  outdated  data  may  appear  to  be  up-to-date  in  user  reports.  This  burdens 
the  user  with  the  cognitive  task  of  assessing  the  validity  and  staleness  of  data.  In  future  efforts,  a 
mechanism  to  update  data  with  meta-information  based  on  feed  status  might  help  to  improve  the 
user  experience. 

For  logistics  feeds,  data  across  the  feeds  is  reconciled  by  a  transportation  control  number 
(TCN).  All  incoming  updates  must  include  a  TCN.  The  TCN  is  used  to  map  records  across  the 
various  feeds  to  a  single  shipment. 


DATA  FEEDS 

An  initial  analysis  of  each  of  the  data  feeds  is  detailed  in  the  following  section.  This  section  is 
incomplete  as  some  feeds  have  yet  to  be  reviewed;  these  sections  will  be  delivered  with  the  final 
analysis  report.  Ultimately,  each  feed  description  will  be  further  detailed  to  provide  higher  accuracy 
and  more  complete  information. 

Logistics  Support  Activity  (LOGSA) 

•  Frequency:  2  or  6  hr 

•  Format:  direct  database  link  or  flat  file  via  secure  file  transfer  protocol  (SFTP) 

The  LOGSA  data  is  broken  up  into  five  separate  feeds.  The  Standard  Army  Ammunition 
System-Modernization  (SAAS-MOD),  Standard  Automated  Maintenance  System  (SAMS),  and 
Standard  Army  Retail  Supply  System-  Level  1  (SARSS-1)  come  from  the  Integrated  Logistics 
Analysis  Program  (ILAP)  and  are  updated  every  2  hr  via  a  direct  database  link.  The  Standard  Army 
Retail  Supply  System-  Level  2  (SARSS-2AC)  come  from  the  Logistics  Integrated  Database  (LIDB) 
and  is  updated  every  6  hr  via  flat  file  transferred  via  SFTP.  Property  Book  and  Unity  Supply  - 
Enhanced  also  comes  from  the  LIDB  and  is  updated  every  2  hr  via  a  direct  database  link. 

The  LOGSA  feeds  provide  closeout  records  for  shipments  received  by  requestors.  The  LDRA 
files  are  closeout  records  from  LOGSA.  They  contain  all  of  the  items  that  have  been  reported  as 
received  at  the  supply  activity.  In  the  NEDP,  receipt  of  an  LRDA  file  will  result  in  deletion  of  all  TCN, 
or  shipments,  from  the  database  that  associated  with  the  LDRA  file. 
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•  LOGSA  Use  Case: 

•  User  generates  closeout  document  for  receipted  materials  in  SARSS.  This 
generates  an  LDRAfile. 

•  LDRA  data  passed  to  the  NEDP  Oracle  database  via  SFTP. 

•  A  procedure  reads  the  LDRA  file  to  extract  the  document  numbers  and 
compare  them  with  the  document  numbers  in  existing  itv_l6_nsn  tables 
and  mark  the  records  found  as  closed.  When  all  national  stock 
numbers  (NSN)  of  a  specific  TCN  are  marked  “Y,”  then  the  TCN  is 
deleted  from  the  BCS3-NM  system. 

•  The  create  LKL  TRP  file  procedure  that  is  triggered  every  15  min  will  include 
the  instances  where  the  TCN  is  to  be  closed  and  next  LKL  TRP  master  or 
delta  file  is  sent  to  the  main  receiver. 

•  The  main  receiver  will  zip  the  file  and  send  it  to  the  subordinate  DFG.  Data 
is  parsed  into  destination  folders  as  a  .gz  file. 

•  Zipped  files  arrive  in  C:\itvrecv\feed  directory  on  the  BCS3-NM  workstation. 
The  LKL  TRP  is  generated  with  a  “Y”  for  the  specified  TCN. 

•  The  TRP  is  parsed  into  a  destination  folder  and  sent  to  the  workstation. 

•  The  TCN  specified  with  a  “Y”  is  closed  along  with  the  lead  TCN. 

U.S.  Marine  Corps  Equipment  Readiness  Information  Tool 

•  Frequency:  24  hr 

•  Format:  flat  file  via  SFTP 

U.S.  Army  Human  Resources  System 

•  Frequency:  24  hr 

•  Format:  flat  file  via  SFTP 

Support  Planning  Integrated  Data  Enterprise  Readiness  System 

•  Frequency:  24  hr 

•  Format:  flat  file  via  SFTP 

Defense  Logistics  Agency  Integrated  Data  Enterprise  Business  System  Modernization  -  Energy 
(BSM-E) 


•  Frequency:  24  hr 

•  Format:  flat  file  via  SFTP 

The  BSM-E  provides  the  NEDP  with  information  on  worldwide  procurement,  inventory, 
shipment,  receipts,  and  distribution  management  of  military  specification  petroleum  products 
including  jet  fuels,  distillate  fuels,  residual  fuels,  automotive  gasoline,  specified  bulk  lubricating  oils, 
aircraft  engine  oils,  fuel  additives,  alternative  energy  technologies,  and  crude  oil.  The  BSM-E  also 
provides  supporting  information  such  as  the  Defense  Energy  Support  Center  centric  Department  of 
Defense  (DoD)  acquisition  advice  codes  associated  to  fuel  tankers. 
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•  The  BSM-E  data  is  received  from  the  integrated  data  environment  (IDE)  via  SFTP 
and  stored  in  the  Oracle  database  until  a  client  makes  a  request. 

•  When  the  clients  request  a  subscription  or  an  on-demand  query,  the  web  server 
submits  the  request  to  the  database. 

•  The  client  goes  into  a  polling  cycle  checking  for  updates  to  the  request. 

•  The  database  generates  an  extensible  markup  language  (XML)  file  that  is  stored  on 
the  web  server. 

•  The  database  only  generates  a  new  XML  file  when  a  matching  file  does  not  exist  or 
when  there  is  newer  data  in  the  database. 

•  Previous  requests  are  stored  in  a  directory;  the  web  server  will  immediately  notify 
the  client  when  the  results  are  available. 

•  When  the  update  is  available,  the  client  begins  to  download  and  parse  the  results 
into  the  local  database. 

Defense  Logistics  Information  Agency,  Asset  Visibility 

•  Frequency:  24  hr 

•  Format:  flat  file  via  SFTP 

The  AV  provides  the  NEDP  with  current  ammunition,  blood,  bulk  fuel  inventory  and  shipment, 
requisition,  unit  equipment,  war  reserve,  and  wholesale/retail  inventory  data.  This  interface  provides 
the  data  that  allows  for  the  capability  to  provide  users  with  timely  and  accurate  information  on  the 
location,  movement,  status,  inventory,  and  identity  of  units,  equipment,  and  supplies. 

•  The  AV  data  is  received  from  the  IDE  via  SFTP  and  stored  in  the  Oracle  database 
until  a  client  makes  a  request. 

•  When  the  client  requests  a  subscription  or  an  on-demand  query,  the  web  server 
submits  the  request  to  the  database. 

•  The  client  enters  a  polling  cycle  checking  for  updates  to  the  request. 

•  The  database  generates  an  XML  file  that  is  stored  on  the  web  server. 

•  The  database  only  generates  a  new  XML  file  when  a  matching  file  does  not  exist  or 
when  there  is  newer  data  in  the  database. 

•  Previous  requests  are  stored  in  a  directory;  the  web  server  will  immediately  notify 
the  client  when  the  results  are  available. 

•  When  the  update  is  available,  the  client  begins  to  download  and  parse  the  results 
into  the  local  database. 

Department  of  Defense  Activity  Address  File 

•  Frequency:  upon  update 

•  Format:  flat  file  via  SFTP 

Federal  Logistics  Data  (FEDLOG) 

•  Frequency:  monthly 

•  Format:  digital  versatile  disc  (DVD) 

The  NEDP  uses  FEDLOG  to  update  the  reference  table  to  associate  a  line  item  number, 
national  item  identification  number,  nomenclature,  or  tables  of  authorized  materiel  to  the  commodity 
items  if  they  are  not  provided  in  the  source  feed. 
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The  NEDP  also  uses  the  FEDLOG  reference  table  to  determine  the  class  of  supply  of  the 
commodities  if  they  are  not  provided  by  the  source  providers.  This  is  done  by  using  the  first  four 
characters  of  the  NSN,  which  is  known  as  the  Federal  Supply  Code  (FSC).  The  BCS3-NM 
references  the  FSC  of  the  NSN  against  a  table  provided  by  the  Office  of  the  Deputy  under  Secretary 
of  Defense  Logistics  and  Military  Readiness. 

The  NEDP  receives  a  monthly  update  of  the  FEDLOG  DVD  that  will  be  used  to  create  a 
monthly  update  (consisting  of  only  add,  deletes,  and  changes)  that  will  be  forwarded  to  the  client 
workstations. 

•  FEDLOG  Delta  data  obtained  from  a  manual  extract  and  compare  will  be  updated  in 
the  Oracle  database  using  import  scripts. 

•  Once  completed,  a  manual  procedure  is  initiated  to  create  a  FEDLOG  and  part 
number  TRP  file  that  is  sent  to  the  main  receiver. 

•  Main  receiver  will  zip  file  and  send  it  to  subordinate  DFG.  Data  is  parsed  into 
destination  folders  as  a  .gz  file. 

•  Zipped  files  arrive  in  C:\itvrecv\feed  directory  on  BCS3-NM  workstation. 

•  The  FEDLOG  and  part  number  TRP  files  are  parsed  into  the  support  database 
replacing  the  appropriate  fields. 

Commercial  Air  Carrier  Data  (21 4A) 

•  Frequency:  unknown 

•  Format:  flat  file  via  SFTP 

The  21 4A  data  is  delivered  in  the  form  of  motor  carrier  shipment  status  messages  that 
support  the  motor  carrier  compliance  application  in  the  form  of  operational  data.  Operational  data 
provides  movement  requirements  to  include  shipment  detail,  routing,  and  carrier  selection  detail. 

This  set  of  transactions  can  be  used  by  a  transportation  carrier  to  provide  shippers,  consignees,  and 
their  agents  with  the  status  of  shipments  in  terms  of  dates,  times,  locations,  route,  identifying 
numbers,  and  conveyance. 

•  The  214  commercial  carrier  data  obtained  from  source  providers  is  updated  in  the 
Oracle  database  using  import  scripts. 

•  Every  15  min,  a  procedure  is  triggered  to  create  an  LKL  TRP  file  that  is  sent  to  the 
main  receiver. 

•  Main  receiver  will  zip  file  and  send  it  to  subordinate  DFG.  Data  is  parsed  into 
destination  folders  as  a  .gz  file. 

•  Zipped  files  arrive  in  C:\itvrecv\feed  directory  on  BCS3-NM  workstation. 

•  The  LKL  TRP  files  are  parsed  into  the  support  database  replacing  all  of  the 
fields. 

•  The  client  can  select  to  stop  receiving  LKL  TRP  files. 

Global  Air  Transportation  Execution  System  (GATES) 

•  Frequency:  unknown 

•  Format:  flat  file  via  SFTP 

The  GATES  supports  headquarters  U.S.  Army  Materiel  Command  (AMC)  fixed  aerial  ports 
and  deployed  aerial  ports.  The  GATES  processes  and  tracks  cargo  and  passenger  information; 
supports  management  of  resources;  provides  logistical  support  information;  supports  scheduling  and 
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forecasting;  provides  tracking  and  tracing  of  aerial  port  assets  (including  personnel,  vehicles, 
equipment,  and  supplies);  supports  processing  service/agency  short-range  cargo  requirements  and 
long-range  passenger  and  cargo  requirements;  provides  passenger  movement  requirements  and 
airlift  capabilities  information  available  in  the  system  to  allow  AMC  to  plan  and  execute  DoD 
international  common  user  passenger  channel  travel;  supports  channel  mission  management; 
manages  tariff  data  regarding  baggage,  passenger,  and  pet  fares;  manages  passenger  reservations; 
and  provides  reports/transportation  status  for  AMC  and  AMC  customers.  The  GATES  processes 
reservations  for  travel  aboard  AMC  owned  and  contracted  aircraft  for  DoD  transportation  offices  and 
provides  premanifests  to  the  GATES  port  level  application  at  fixed  aerial  ports  and  contracted 
commercial  airport  gateways  worldwide. 

•  The  GATES  data  obtained  from  source  providers  are  updated  in  the  Oracle 
database  using  import  scripts. 

•  Every  15  min,  a  procedure  is  triggered  to  create  an  LKL  TRP  file  that  is  sent  to  the 
main  receiver. 

•  Main  receiver  will  zip  file  and  send  it  to  subordinate  DFG.  Data  is  parsed  into 
destination  folders  as  a  .gz  file. 

•  Zipped  files  arrive  in  C:\itvrecv\feed  directory  on  BCS3-NM  workstation. 

•  The  LKL  TRP  files  are  parsed  into  the  support  database  replacing  all  of  the 
fields. 

•  The  client  can  select  to  stop  receiving  LKL  TRP  files. 

Radio-frequency  Identification  (RFID)  Detections,  Level  6,  and  Interrogator  Locations 

•  Frequency:  15  min 

•  Format:  direct  database  link 

The  NEDP  uses  a  materialized  view  of  the  database  replication  between  the  NEDP  and  the 
radio  frequency  in-transit  visibility  (RF-ITV)  regional  data  server  to  get  updates  every  15  min.  Radio 
frequency  burn  data  is  linked  with  the  shipping  containers  (e.g.,  pallets,  loaded  military  vans, 
Container  Express  containers,  etc.)  to  identify  and  track  contents.  The  RFID  data  includes  TCNs 
associated  with  the  shipment  data  along  with  commodity  level  detail.  Cargo  with  an  RF  tag  updates 
the  RF-ITV  regional  data  server  as  they  pass  by  interrogators.  This  data  feed  is  received  on  both  the 
nonsecure  internet  protocol  router  (NIPR)  and  the  secure  internet  protocol  router  (SIPR)  networks. 

This  RF  data  is  then  merged  with  the  International  Data  Environment/Global  Transportation 
Network  Convergence  (IGC)  data  using  custom  queries  to  fill  in  missing  data. 

•  Replica  of  Joint-Automatic  Identification  technology  (J-AIT)  database  is  stored  on 
the  NEDP  Oracle  database. 

•  Materialized  view  of  the  BCS3  Oracle  is  stored  in  the  BCS3-NM  Oracle.  Every 
15  min,  a  procedure  is  triggered  that  merges  the  RF  data  with  the  IGC  data  to 
create  an  LKL  TRP  file  that  is  sent  to  the  main  receiver. 

•  Main  receiver  will  zip  file  and  send  it  to  destination  clients.  Data  is  parsed  into 
destination  folders  as  a  .gz  file. 

•  Zipped  files  arrive  in  C:\itvrecv\feed  directory  on  BCS3-NM  workstation.  The  data  is 
not  displayed  in  BCS3-NM  until  a  filter  is  created  that  includes  the  TCN  data. 

•  The  LKL  master  files  are  parsed  into  the  support  database  replacing  all  of 
the  fields. 

•  Deltas  will  append  data  to  the  fields  generated  by  the  master  TRP. 
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•  The  client  can  select  to  stop  receiving  LKL  TRP  files  if  desired. 

Transponder  Location  5.13  Extensible  Markup  Language  Feed 

•  Frequency:  real  time 

•  Format:  XML  via  hypertext  transfer  protocol  secure  (HTTPS)  web  service 
This  data  feed  is  received  on  both  the  NIPR  and  SIPR  networks. 

Last  Tactical  Mile  in  Transit  Visibility  (LTM-ITV) 

•  Frequency:  real  time 

•  Format:  flat  file  via  Theater  Information  Management  (TIM)  HTTPS 

The  LTM-ITV  provides  BCS3-NM  with  a  satellite-tracking  system  that  also  includes  the  ability 
to  track  RFID  tags  associated  with  the  vehicle  that  is  transporting  it.  This  information  allows  BCS3- 
NM  to  view  the  contents  of  an  RFID  from  the  point  it  is  loaded  on  a  vehicle  to  the  point  it  is  delivered. 

The  LTM-ITV  contains  transponder  locations  during  shipments’  last  tactical  mile.  The  LTM- 
ITV  data  along  with  transponder  data  received  from  the  J-AIT  and  Global  Deployment  Management 
System  (GDMS)  data  providers  are  populated  in  the  NEDP  Oracle  database.  The  data  from  these 
tables  is  used  to  generate  the  13  different  TRACK  TRP  files  that  are  transferred  to  the  structured 
query  language  (SQL  EXPRESS)  support  database  on  the  BCS3-NM  client.  The  data  received  from 
LTM-ITV  that  contains  associated  RFID  or  lead  TON  cargo  will  be  merged  into  to  the  LKL  tables.  If 
the  cargo  does  not  contain  an  RFID  or  lead  TON,  it  will  only  be  associated  with  the  vehicle  that  is 
transporting  it. 

World  Port  System 

•  Frequency:  upon  request 

•  Format:  flat  file  via  STFP 

Integrated  Booking  System  -  Container  Management  Module 

•  Frequency:  1  hr 

•  Format:  flat  file  via  SFTP 

Movement  Tracking  Systems 

•  Frequency:  on  use 

•  Format:  XML  and  SMTP  via  a  virtual  private  network  (VPN)  connection 
Global  Transportation  Network  (GTN) 

•  Frequency:  on  use 

•  Format:  GTN  query  via  secure  shell  tunnel 

Global  Deployment  Management  System 

•  Frequency:  real  time 

•  Format:  flat  file  via  TIM  HTTPS 
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The  GDMS  provides  the  NEDP  with  information  from  commercial  satellite-tracking  systems 
feeds.  The  GDMS  transponder  information  is  merged  with  data  received  from  the  LTM-ITV  and  J-AIT 
feeds. 

Global  Combat  Support  System  -  Army  Analysis 

Although  current  GCSS-A  planning  includes  replacement  of  all  LOGSA  data  sources,  this  will 
not  impact  the  NEDP.  The  GCSS-A  is  gradually  decommissioning  the  LOGSA  servers.  Current 
understanding  is  that  as  this  happens,  GCSS-A  will  being  to  provide  the  AV  data  to  LOGSA.  The 
LOGSA  will,  in  turn,  provide  this  data  to  the  NEDP;  thus,  the  NEDP  will  continue  to  consume  this 
data  through  LOGSA.  The  GCSS-A  currently  has  no  requirements  to  interface  directly  with  the 
NEDP  or  TacApps.  This  will  only  become  an  issue  if  a  future  version  of  TacApps  needs  access  to 
GCSS-A  data  directly. 


CONCLUSIONS 

The  National  Enterprise  Data  Portal  (NEDP)  is  a  large,  complex  system  ingesting  data  from  a 
multitude  of  sources.  Initial  analysis  indicates  integrating  the  NEDP  into  Tactical  Applications 
(TacApps)  and  the  command  post  computing  environment  will  be  a  nontrivial  task  with  a  significant 
level  of  effort  required.  The  feasibility  of  integrating  the  feeds  directly  into  the  Mission  Command 
Data  Service  (MCDS)  without  the  use  of  the  NEDP  has  yet  to  be  determined.  The  remainder  of  the 
Battle  Command  Sustainment  Support  System  (BCS3)/NEDP  analysis  will  focus  on  reviewing  the 
remaining  data  feeds  and  BCS3  software  to  achieve  the  following  goals  that  align  with  the  original 
analysis  plan: 

•  Provide  rationale  that  recommends  either  integrating  NEDP  with  TacApps  or 
consuming  feeds  directly  into  the  MCDS. 

•  Reduce  the  cost  and  schedule  needs  of  future  BCS3  TacApps  integration  efforts  by 
understanding: 

•  Data  model  implications. 

•  Data  throughput,  bandwidth,  and  storage  needs. 

•  Conflict  resolution  and  business  logic  requirements. 

•  Document  data  and  interfaces. 

•  Understand  system  and  domain  to  assist  with  estimating  BCS3  TacApps  integration 
cost  and  staffing  requirements. 

The  TacApps  team  expects  that  these  goals  will  be  achievable  in  the  timeframe  given, 
provided  that  Tactical  Edge,  Inc.  engineering  support  continues  to  be  available  and  forthcoming.  As 
key  areas  of  the  NEDP  are  illuminated,  current  technical  planning  includes  involvement  of  current 
Semantically  Extensible  Attribute  Model  (SEAM)  2.0/Mission  Command  Data  Model  modelers  and 
MCDS  developers  in  the  BCS3  analysis  for  both  input  and  situational  awareness.  The  addition  of 
these  personnel  is  key  to  understanding  the  implications  of  logistics  data  integration  into  MCDS  and 
will  result  in  a  more  complete  final  analysis  report. 
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